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(57) Abstract: An online machine data collection 
and archiving process (15) generates a machine data 
profile (18) of a customer computer (5) accessing a 
transaction form of a merchant web site (3) and links the 
machine data profile (18) and a transaction record (6) 
with customer identifying information using a unique 
transaction identification string. The process preferably 
captures parameters typically communicated as part of 
web accesses, such as an IP address, an HTTP header, 
and cookie information. The process additionally causes 
the customer computer (5) to process self -identification 
routines by processing coding within the merchant 
transaction form, the self-identification routines 
yielding further profile parameters. The process further 
includes a routine for bypassing an intervening proxy 
to the merchant web site (3) to reveal the true IP address 
of the customer computer (5). 
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1 ONUm MAGHIME DATA COLLECTION AND ARCHIVING PROCESS 

2 

3 Cross-Reference to Provisional Application 

4 This application clsdms benefits from provisional application. Serial No. 

5 60/209,936 filed June 7, 2000 and entitled METHOD FOR COLLECTINGMACHINB 

6 DATA FROM CUSTOMERS ON A COMPUTER NETWORK 

7 

8 Background of the Invention 

9 The present invention relates to identity detection techniques and, more 

1 0 particulariy, to a process for collecting and utilizing machine-identt^g data of compute 

1 1 and other online appliances used in online interactions and transactions and associating the 

1 2 collected machme data ^th such onlme int^ctions. 

13 The internet, or global conq>uter netv^ori; rq)resents a new mediumfor maik^ing 

1 4 similar to the way mail ordering and telephone ordering did m the past A downside of 

15 internet marteting is that it also presents new opportunities for unscrupulous persons to 

1 6 take advantage of the mechanisms of internet transactions by firaudulent and deceptive 

17 practices. Merdiants and finandal institutions bear the imtihl costs Hoivever, 

1 8 consume ultimately pay the costs in the form of prices and credit rates wUch must take 

1 9 into accoxmt losses firom firaud. Internet purchases typically involve the use of web page 
2 0 forms which are filled in by the customer vdtii identity, address, purchase, shipph^ and 

1 
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1 pasrmeotiiifonnation and submitted to the onlm Internet 

2 piuxshasesaie most oftra paid for by way of ccedit cards. While a merchant's software 

3 may be able to verify the existence and status of a credit card account number and an 

4 aufhoization for a spedfic amount, the merdiant is often not able to match a credit card 

5 number with a spedfic purchaser or shipping address. Thu^ abs^ any ovot indication 

6 otherwise, a merchant g^erally assumes that anyone using a onedit oard is authorized to 

7 do so and that a customer is he identifies himsdf to be. 

8 An in^ortant step in combating fi-aud is accurate identification of the computers 

9 throu^ which customs make transactions and assodating such identities with 

1 0 transactions which arouse suspidons or which ultimately turn out to be firaudulent. Bade 

11 madune identity is essential to the manner in which the internet opmtes. We speak in 

12 terms of "going" to a web site. In reality, "going" to a web site involves sending a request 

13 fi>rawd)pagefiIeinadttectoryorfi>lderonacomputarlocatedat a ^ecific internet 

14 protocpl, or IP, address. In order for the wd) page file to be returned to the requesting 

15 computer for processing into a displayed *Vd) page", the request must indude retum 

1 6 "directions" in the form of the basic identity of the requesting computer, includimg its IP 

17 address. Some web sites are implemented witii software which enables responses to wd> 

1 8 page requests to be tailored to specifics of tiie requesting rtadiine's configuration, spedfic 

1 9 web browser, and the like. For this reason, current versions of browsers usually 

20 conmmnicatecon5gunitioninfi>nnation in addition to a return IP address and return path. 
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1 The IF address of a page requesting computer can give an indication of the specific 

2 country where the computer is located. • Furth^, id^tification of a page-requesting^ 

3 computer can also recognize a returning user using the same computer as during a 

4 previous access. For example^ pladng an HTTP Oiyporte?ct transfer protocol) ''cookie" on 

5 a page-requesting computer can make it possible to identify the computer on a later 

6 access. 

7 Because dkect int^action with a customer's computer is essential in detecting 

8 firaud, it has been assumed that any viable fraud detection software must be integrated with 

9 a merdiant's software. As a result^ most e»stingfiaud detection solutions require 

1 0 merchants to either abandon or extensively modify thdr existing web-based transaction 

11 procesang software. An additiond problem with fdcussngftwd detection at singjle 

1 2 merchants is that perpetrators of fraud often hit many merchants in an attempt to avoid or 

1 3 delay detection. Thus, an ideal system for fraud detection in online marketing would onfy 

1 4 minimally affect the merchant's existing software and would route fraud detection efforts 

15 through a central, tfakd-party entity serving a large multitude of merchants. 
16 

17 Summary of the Invention 

1 8 The present invention provides a process for collecting data associated with a 

1 9 customer's computer during access of a merchant, financial, other host web site, and 

2 0 associating a transaction identification numb^ with the data and with a transaction form of 

21 the merchant. Generally, the present invention captures machme identifying data from a 
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1 conqjuter or other digital appliance accessing a host web site, sends the captured data to a 

2 machine data archive along with a unique transaction identification string fer storage in the 

3 archive and writes the same transaction identification string into a transaction form 

4 tiirougih which transactions with the host web site are conducted. The machine data is» 

5 thus, associated with the customer identification data within the transaction form by w^ 

6 of the transaction identification string and can be used on-the-fly or at a later time for a 

7 variety ofpurposes including, but not limited to, fiaud detection. Although the terai 

8 "archive" is used, the nmdime data collected need not be stored pennanently. 

9 The machme data collection process of the presoit mvention is mtended to be 

1 0 employed m a variety of applications including, but not limited to: onlme purchases and 

1 1 orders; online banking, bill p^ent, and fiinds transfers; online r^istrations, such as for 

12 memberships, product warranties, ^plications for credit, renewal of subscriptions and 

13 licenses; online technical support; and the like. The term "transaction" is used in the 

14 present invention to describe an interaction effected between a digital ^pliance and a host 

1 5 system. However, the term "transaction" is not mtended to be restricted to only 

16 commerdal interactions invohang purchases. The term "transaction" is intended to appty 

17 to an interaction of a rmote digital ^pliance with a host system using a relatively 

1 8 anonymous type of access process over a digital medhmi mi'wirich some fonn of sdf- 

19 identification of tiie accessing appliance is inherent in tiie access process and in which the 

20 true identity of the accessmg party, the trae source address of tiie appliance on tiie 
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1 medium, and/or the true machine characteristics of the accessing appliance is/are essential 

2 or de^rable to the interaction. 

3 The host entity which operates the host system accessed is intended to encompass 

4 a commerdal, financial, educational, governmental, assodational, or other type of entity. 

5 The term '"merchant" will be used herein to refer to such a host entity without intent to 

6 limit the presmt invention to commerdal transactions. The medium of access is intended 

7 to be interpreted as including a global compute network such as the internet or world 

8 wide web, as well as other types of networks which may be less than g^lobal but \^di are 

9 publicly and/or anonymously accessible. The term ""intemef will be used hmin to refer 

10 to the medium through which accesses to the host entity are made. The terms ""customer 

1 1 computed* or ""machine" are used herein to refer to a device for effecting r^ote access to 

12 a host ^stem over a digital mecfium and are meant to encompass not only conventional 

1 3 types of personal computers, but also additional types of '"(fi^tal appliancei^ with online 

1 4 access capabilities, such as: cell phones, personal digital assistant devices, electronic game 

1 5 systems, television sets with online access capabilities^ web appliances for vehicles, and 

1 6 any other type of device with online access capabilities whether connected to a wired 

1 7 communications network directly or by a radiant technology. 

1 8 The machine data collection process of the present invention contemplates a two 

1 9 party process embodiment m which a ""merchant processes and/or stores machine data 
2 0 profiles of customer computers in-house, as well as a tiiree party process embodiment in 
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1 vMch. macbine data profiles of customer computers are processed and/or stored for the 

2 merchant by a third-party machine data collection and archive service. 

3 In a two partjrembodimontofthe data collection process of the present inventioi^ 

4 the customer machine data is captured by a m^duint or host system which also genmtes 

5 a unique transaction identification (ID) string and assigns or assodates the transaction ID 

6 with a machme data profile ofthe customer madune data projBle. Ihthetwoparfy 

7 process, the merchant system captures customer computer data which is inherently passed 

8 &om the customs compute- to the merdiant's web sat% such as an IP addiess ofthe 

9 cus^mer computer and an HTTP header. Additional^, according to the present 

1 0 invention, the merchant wd) page code may have routines or calls for ejctemal routines 

1 1 wbif^ when processed by the customs* computer, cause the customer conpiter to 

1 2 fiitther identify itself by collecting and returning certain machine and software 

1 3 configuration charactoistica, wfaidi can be used to idoitify the particular customer 

14 con^uter. The two party process may include the generation and setting of an HTTP 

15 cookie in the customer browser for recogmtion upon a later access with the niercham 

16 site. 

1 7 Although the two-party embodimait of tiie machine data collection process ofthe 

1 8 present invention has utility fi>r some applications, the three party enibodimait is preened 

1 9 for applications in wludi analysis of a maximum number of customer computer profiles is 
, 2 0 dearabl^ such as certain types of maiketing processes and fi^d detedion and control 

2 1 processes. In a three embodiment of the preset invention, the customer machine data of 
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1 computers accessdng the second party or merchant web site is communicated to and stored 

2 ^thin a third party system, referred to herein 9S a machme data arcMve^^ In the . 

3 three party process, the transaction ID could be gen^ted by the m^chant system, but is 

4 pr^erably generated by the archive service. The use of the term **archive" is not meant to 

5 indicate that the customer machine data profiles are stored permanently within the third 

6 party system. Permanent storage of such profiles may not be practical, as &r as yielding 

7 beneficial results to the purposes for which the profiles are collected Thus, the term 

8 ''archive'' is meant to indicate a central storage &dlity, sudi as a database, with a selected 

9 retention period, vdth purging of most profiles after a certam length of time. 

10 In the three party process a routine or line ofcode is added into the hyp^ex^ 

1 1 markup language (HTML) code which defines the merchant's web page, particular^ an 

1 2 order or transaction form page. The added routine issues a request for a machine data 

1 3 collection (MDC) script to the thk-d-party web ^e vfbm the form page code is processed 

14 by the customer's browser. When the script request is received by the machine data 

15 archiving service (I^AS), the arcluveserdce generates a u^ 

1 6 identification (J A/ID) and checks for its own cookie. If no MDAS cookie is present, the 

1 7 archive service sends a cookie to the requesting computer along with a machine data 

1 8 collection (MDC) script havmg the transaction ID embedded therdn. The MDC script is 

1 9 executed by the customer's browser, causmg collection of c^ain data firom the 

2 0 customer' s computer vdiich is sent back to the archive service along with the transaction 

21 ID and stored in a machme data profile in the machine data archive. The transaction ID is 
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1 imtten into the transaction fonn, and when the transaction form is submitted to the 

2 merch^t web site, the transaction ID string becomes a part of the transaction data record, 

3 along ^vith customer identification, location, and finandal information. 

4 The machine data initially collected and stored m each profile preferabtjr includes 

5 the transaction ID, the apparent IP address of the customer's computer, a conventional 

6 HTTP head^ yAjidk identifies the customer's browser versions and certain configuration 

7 aspects of the browser, and the archive servicers cookie. The combination of such 

8 information, minus the transaction ID, will be relativdy rare but may not be unique. 

9 Additionally, customers intent on conducting fimidulent transactions ofi:en hide their IP 

10 address bdiind HTTP proxies. In order to fiirther narrow the machme profile, in a 

1 1 preferred embodiment of the present invention, the MDC script performs ad(fitional 

1 2 machine profiling operations: generation of a machine '"fingerprint" and a proxy 

1 3 "^ierdng" operation. 

14 In the fingerprint generation operation, the MDC script assembles an attribute 

1 5 string formed by various attributes or configuration settmgs of the browser wMch can be 

1 6 queried by the script. The MDC script then performs a conversion process on the 

1 7 attribute string to generate a fingerprint string having content which is a fimction of the 

1 8 original content of the attribute string. The conversion probess is preferably a 'liashing" 

1 9 function which is, in effect, an irreversible encryption algorithm. The generation of a 

2 0 conventional checksum is one example of a type of hashing fimction. For example, if the 

2 1 attribute string is formed by alphanumeric characters, the conversion process is performed 

8 
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1 on tile string of codes representing tiie charact^. The particular conversion process or 

2 liashing fUnction used may be one of many typ^s of conventional conversion algorithms or 

3 hashing Amotions, which are typically used for data mtegrity tests. The resulting string 

4 from the MDC conversion process is a so<-caIled fingerprint, which is returned to the 

5 archive service along with the transaction ID for storage in the machine profile. A time 

6 value, queried fi-om the customs computer time-of*day clock, is retumed with the 

7 fingerprint string and stored in conjunction therewith. 

8 An HTTP proxy is one of sev^ types of proxies throu£^ which a browser may 

9 be setup to operate. Setting up an HTTP proxy causes HTTP requests to be relayed by a 

1 0 primary gateway, through which the computer actually interfaces to the intemet, to a 

11 remote secondary gateway, or proxy, with an IF address different firom the prima^ 

12 gateway IP address. Such redirection hides the true IP address of a computer. The proxy 

1 3 piercing operation of the MDC script queries the customer con^uter for any LAN (local 

1 4 area network) address which may be assigned to the computer and reads the system time 

15 of d^ dock. Then attempts are made to send the LAN address^ if any, the time value, 

1 6 and the transaction ID to the archive service using a protocol which will not be redirected 

1 7 tiirough the HTTP proxy, for example a lower level protocol such as TCP /IP or UDP 

1 8 protocols. U^the attempt is successfiil, the message contaii^g the time value, the 

1 9 transaction ID, and LAN address arrive at the archive service web site with the true return 

20 IP address of the customs computer, whether an HTTP proxy int^enes or not. The 

2 1 LAN address and IP address so derived are stored in the machine profile. It should be 
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1 noted that the use of an HTTP proxy is not, of itsd^ an indication of fiaud. However, the 

2 acquiation of an additional IP address is one more puweter vdth which to identify a 

3 particular computer. 

4 When, and i^ the custom^- submits the transaction form to the mexdiant, the 

5 transaction ID string is communicated to the merchant along with oth^ customs 

6 Infinmation sudi as name, address, credit card number and the like phis transaction 

7 information. The complete transaction record is stored on the merchant's system and is 

8 associated with a spedfic madime idoitity profile witiiin the archive service by way of the 

9 transaction ID string. Thereafter, tilie stored machme identity profiles and transaction 

1 0 records of large numbo^ of transactions can be analyzed by various fi:aud detection 

1 1 techniques to detect patterns of fi:aud and fi^d attempts an^ preferably, identify and 

1 2 locate the soiHces of such activity. 

1 3 The madime data profiles stored m the ardiive so^ce need not be combined with 

14 the customer identification information for non-suspidous transactions, to tiierd>y 

1 5 preserve the privacy of non-suspidous customers within the madime data ardiive. 

1 6 Hbwever, the processes of the present invention do not require that the customer 

1 7 identification infisnnation be separated &om any assodated machine data profiles^ and 

1 8 there may be reasons to conibme the assodated records. 
19 

20 
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1 Brief Descriptioii of the Drawings 

2 Fig. 1 is a simplified block diagram illustrating a plurality of customer and 

3 merchant computers inter&ced to the intemet along with a machine data archiving service 

4 computer for practidng the machine data collection process of the present invention. 

5 Fig. 2 is a simplified block diagram illustrating connection of a customer computer 

6 to the internet, whh optional componrats shown m phantom lines. 

7 Fig. 3 is a flow diagram illustrating prindpai steps of the machine data collection 

8 and archiving process accordmg to the present invention. 

9 Fig. 4 is a flow diagram illustrating more detailed steps of the machine data 

1 0 collection and archiving process accordmg to thie present invention. 

11 Fig. 5 is a flow diagram illustrating a stillfiirther detailed steps in the machine data 

1 2 collection and archiving process of the present invention. 

1 3 Various objects and advantages of this mvration will become appar^ fiom tibie 

1 4 following description taken in relation to the accompanying drawings wherein are set 

1 5 forth, by way of ilhista-ation and example, certain embodunents of this invention. 

16 The drawings constitute a part of this spedfication, include exemplary 

1 7 embodunents of the present invention, and illustrate various objects and features thereof 
18 

19 
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1 Petafled Description of the Invention 

2 As required, detailed embodiments of tbe preset invention are disclosed herein; 

3 however, it is to be understood that the disclosed embodiments are merely exemplary of 

4 the invention, which may be embodied in various forms. Therefore, specific structural and 

5 fimctional details disclosed herein are not to be interpreted as limiting, but merely as a 

6 ba^ for the clauns and as a rq)resentattve basis for teaching one skilled in the art to 

7 variously employ the present invention in virtually any appropriately detailed structure. 

8 Referring to tiie drawings in more detail: 

9 The ref^^ce numeral 1 (Fig. 3) gen€a:ally designates 

10 a process for online collection of machine identifying or profiling data of computers 

1 1 involved in commerdal transactions and for archiving such data to &dlitate analyds for 

12 firaud detection purposes. The process coHects machine identifying or profiling data of 

1 3 con^ters involved in commerdal transactions and archives such data in a third-parly 

1 4 machine data archive service in assodation with a transaction identification string or ID 

1 5 whidi is also written into a transaction form of a merchant with whom the customer is 

1 6 conducting a transaction. 

1 '7 Fig. 1 ilhistrates a plurality of host entities or merchants with corresponding 

1 8 merchant computers 2, on which are operated merchant web ^tes ivvbich are accessible 

19 over a gjobal computer network, such as the internet 4, by a plurality of customer 

2 0 con^uters 5. The merdiant computers 2 execute various programs wMch enable the sale 
2 1 of products or services by way of the intemet 4, The merchant web sites 3 typically make 

12 
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1 use of fomi type web pages with which the customers 5 interact by filling in various data 

2 fidds^ for example, name, address, shipping address, telephone number, credit card type 

3 and number and miration date, and description and quantities of products to be ordered. 

4 The merchant transaction forms are usually written in hypertext maricup language 

5 (HTML) and may include requests for code written in other languages, such as Java and 

6 the like. When a customer 5 accesses a merchants transaction form, a transaction fomi 

7 file is communicated to the customer's computer with various data fields displayed as fill- 

8 in boxes or the like. The customs fills in the appropriate fields and selects a submit 

9 "button" which activates a routine to tma^et the collected information back to the 

1 0 merchant web site 3 for processing. The returned "form" is a data record 6 which is 

1 1 stored m a merchant transaction database 7 for retrieval and processing in due course to 

1 2 cause the ordered items to be gathered, packaged and prepared for shipment, along with 

1 3 finandal processang to debit the customer's credit accoimt. The finandal proces^ng may 

1 4 include a validity check of the credit account and an authorization check for the amount of 

1 5 purchase with the acedit card issuer. Additionally, inventory management processes are 

1 6 executed based on the items withdrawn fi^om stock for shipment. 

17 Li a three party embodiment of the present invention, the process 1 makes use of 

18 an entity referred to herein as a machine data archiving service, MDAS or archive service, 

1 9 which operates an archive service computer system IS, including an archive service web 
2 0 site 16. The archive service i^em IS maintains a machine data archive service database 
21 or archive 17 in which the machine data collection profiles 18 fi-om customer computers S 

13 
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1 of the merchants 2 are stored* The archive service web site 16 is inter&ced to the internet 

2 4. The archive service 15 is preferably mdependent of the merchants and may be operated 

3 by a merdiants* association, a financial institution or association thereoi^ or may be an 

4 independent contractor. Alternatively, it is conceivable that a merchant ^vith a high 

5 volume of online sales could operate its ovm in4iouse machine data profile collection and 

6 archiving service IS, for fraud detection or pos^bly for marketing purposes. 

7 Referring to Fig. 2, a customer computer system 5 includes a customer computer 

8 20int^&cedtotheintemet4byway ofapximaiygateway22, asofanin^ 

9 provider (ISP). The computer 20 niight be one ofmany on a local area netvvork or LAN 

10 24 which mchides a router or svntch wluch routes data from fiie mtemet 4 to the 

1 1 computers on the network. The computer 20 may communicate througih the mtemet 4 by 

12 way of a HTTP (hypertext transfer protocol) proxy 26, whidi disguises the internet 

1 3 protocol (EP) address of the actual gateway 22. The computer 20 accesses web sites on 

14 the internet 4 using a customer web browser 28 which processes HTML language and 

1 5 various other standard web oriented languages to display or otherwise render the content 

1 6 of web pages and mteract therewith. The browser 28 is normally enabled to accept 

1 7 "cookies'' 30 which are stored in a cookie file. Cookies 30 are data strings which are 

1 8 issued by web sites and give an mdication of a previous visit to a particular web site and 

1 9 may indicate a particular configuration or set of preferences of the customei's setup of the 
2 0 con4)uter 20. Typically, the customer computer 20 has a time of day dock/cal^dar 32. 
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1 The customer compiiter 20 may have a fixed IP address, d^ending on the maimer 

2 in which it is int^&ced.to the internet. More commonly, the customer con^puter 20 will: 

3 have a temporary or dynamicatty assigned IP address which is determined by the primary 

4 router22. The primaiy router 22 has an IP address, as do a router ofa LAN 24 or an 

5 HTTP proxy 26 if either is present in the customer's computer system 5. 

6 Fig. 3 illustrates the piindpal actions or steps of a general or basic proems 34 of 

7 the process 1 for collectitig machine identifying data £rom customer computers 5. At step 

8 35, at least one machine identifying profile paramet^ is captured upon access of a 

9 customar computer S or other online access device with a host or m^chant web site 3. A 

1 0 unique transaction idmtifier or TA/ID is g^erated at 3 6 and associated at 37 with the 

1 1 captured profile parameter. The transaction ID is also associated at step 38 with a 
. 12 transaction record generated as a result ofthe interaction or transaction conducted 

1 3 between the customer computer 5 and a merdiant web mte 3. Although! not spedficalfy 

1 4 shown in Fig. 3, the process 34 may capture machine profile data that is passed firom the 

1 5 customer computer 5 to the merchant computer 3 as an inherent step of the customer 

1 6 compute S accessing the merchant computer 3 . Alternatively, the process 34 may pass 

1 7 routines to the customer computer 5 to cause it to ^^sdf-identify** itself by querying certain 

1 8 configuration parameters and pasdng such information to a machine profile stored either 

1 9 withm the merchant's system 2 or in a third party archive 17. The process 34, thus, 

2 0 encompasses a two-party mbodiment or a three party embodiment ofthe machine data 

2 1 collection and archiving process 1 of the present invention. 

15 
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1 Refening particularly to Fig. 4, a more particular tiiree party embodiment of the 

2 machine data collection and archiving process 1 begins at step 40 with the coding of a 

3 machine data collection (MDC) script request into the web page code for a transaction 

4 form of a merchant wdb dte 3. When a customer 5 accesses the merchant transaction 

5 form at step 42, the customer browser 28 processes the transaction page code, including 

6 the MDC script request, vrbkk causes the MDC soipt request to be communicated to the 

7 archive s^ce web site 16 at step 44. The script request anives at the archive service IS 

8 with a set of customer machine parameters which prindpally provide a return path for the 

9 MDC script from the archive s^ce 15 to the customer S. The customer machine 

1 0 parameter set preferably includes "user agent" information, which is the version of the 

1 1 customer browse 2&. 

12 At step 46, the archive service IS generates a unique transaction ID string and 

1 3 assodates it with the customer machuie paramettf set in the MDAS archive 17. At step 

1 4 48, the ardiive service returns the MDC script, with the transaction ID embedded within 

15 i1^ to the customer browser 28. At step SO, the customer browser 28 processes the MDC 

1 6 smpt which, at a minimum, writes the transaction ID string into the merchants transaction 

1 7 form. Assuming that the customer S completes the transaction and submits the transaction 

1 8 form to the merchant 2 at step 52, the transaction ID string Is stored with the transaction 

1 9 data record 6 in the merchant transaction database 7. The transaction ID, thus, indirectiy 
2 0 associates the machine data paramet^ set 18 stored in the MDAS archive 17 at st^ S4 

2 1 with the customer identity information stored with the transaction data record 6 in the 

16 
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1 merchant's transaction database 7. Thereafter, qualified parties may access the MDAS 

2 archive 17 for information related to a transaction ID« 

3 The MDAS archive 17 need not contain any information which specifically 

4 identifies a particular customer, only the machine parameter profiles 18 with associated 

5 transaction ID strings. The MDAS archive records 18 can be analyzed in conjunction with 

6 the merchant transaction records for patterns of fimid or for other purposes. The great 

7 majority of MDAS archive records can be purged from the archive 17 after a selected 

8 period of time. Any records wUch are associated with aiiy transaction uregularities or 

9 suspicions of actual firaud may be retained longer. 

1 0 Fig. 5 illustrates the principal steps of a preferred embodiment 60 of the machine 

1 1 data collection and archiving process 1 of tiie present mventioa The process 60 begins 

12 with the addition at 62 of a machine data collection (MDC) script to the transaction (TA) 

1 3 form page code of a merchant web site 3. The transaction form page code is processed at 

14 64 by a customer browser 28 when the iherchant web page is accessed to thereby request 

15 the MDC script at 66 fi-om the Machine data archive service (MDAS) web site 16. When 

16 the browser 28 accesses the MDAS web site 16, requestmg the MDC script, the MDAS 

17 web site checks for the presence of an MDAS coolde at step 68. If no MDAS coolde is 

1 8 detected, an MDAS cookie is generated at 70 and a unique'iransaction identification 

1 9 (TA/ID) string is generated at 72. The MDC script, transaction ID, and cookie, if not 
2 0 pre^ously set, are returned at 74 to the customer browser 28, the transaction ID bdng 
2 1 embedded within the MDC script 

17 
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1 When theMDC script is received by the browser 28, it is executed at 76. The 

2 cookie is stored in the cookie file 30, orpossibjy in the memory of the customer computer 

3 20, Execution of a prefen^MDC script causes several actioiis to be performe^^ The 

4 MDC script writes the transaction ID into the transaction form at step 78. The script can 

5 do this by either setting an ^sting variable of an appropriate name to the transaction ID 

6 string or by writing an appropriate variable into the transaction form page and setting its 

7 value to the transaction ID string. Additionally, the preferred MDC soipt generates a 

8 '"fingerprint" of the customer computer 20 at step 80 and attempts to perform a praxy 

9 piercmg operation at step 82. 

10 Li generating the machine fingerprint at 80, the MDC script queries the browser 28 

11 for a number of attributes and settings and concatenates the results into an attribute string 

12 at 84. The MDC script then performs a hashing algorithm on the attribute string at 80 to 

13 generate a fingerprint strii^\vMch has a high degree of uniquene^^ Has^img fiinctions are 

1 4 irreversible encryption processes in which the result is dependent on the original content of 

15 the data on which the hailing algorithm is operated. Haslm^ fimctions are commonly 

1 6 used for data integrity checking. As previous^ stated, a common checksum is the result 

17 of a type of hashmg fimction. The particular hashing fimction employed preferably 

1 8 maximizes the uniqueness of the resulting fingerprint 

19 At step 86, the customer computer clock 32 is queried for a current time value. At 

20 st^ 88, the fing^rint, the transaction ID, and the time value are communicated to the 

c 
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1 MDAS web site 16 along with an HTTP head^ with cookie and ""apparent" IP address, all 

2 of whidi are stored as « machine data profile 1.8 within the MDAS archive 17. 

3 At step 90, the MDC script adds a prox3r piercer request to the transaction form 

4 wfaicli, when executed by the browser 28 at step 92, sends a request for a proxy piercer 

5 applet or code to the MDAS web site 16. When the proxy piercer applet/code is executed 

6 by the browser 28 at 94, a time value from the clodc 32 is again queried at 96 and any 

7 existing local area network (LAN) address is queried at 98. At step 100, the proxy piercer 

8 applet/code sends the time value, the LAM address (if any), and the transaction ID to the 

9 MDAS web site 16 by a protocol which bypasses any existing HTTP proxy 26. The 

1 0 protocol used is one which is at a lower level than HTTP, such as UDF (ustt datagram 

1 1 protocol) or, preferably, TCP/IP (transmission control protocol^temet protocol). 

12 Bypassing the HTTP proxy 26 causes the data sent in step 100 to anive at the 

1 3 MDAS web site 1 6 with the IP address of the piimaiy gateway 22, which may be different 

1 4 from any apparent IP address previously recorded if an HTTP projcjr 26 mtervenes. If the 

1 5 proxy pi^cer procedure 82 is success&l, the primsury gateway IP address is stored at step 

1 6 102 withm the machine data profile 18 identified by the transaction ID. It should be noted 

17 that some types of proxies, such as some types of firewalls, may block all non-HTTP 

» 

1 8 protocol padcet^ so timt the proxy pio-cer procedure 82 iniight not be success&l in all 

19 cases. 
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1 If the customs completes tiie transaction -with the merdiant w(h site 3, the 

2 transaction foim is sub^iitted at step 104, which causes the transaction record 6, induding 

3 the transaction ID, to'be stored at step 106 in the m^chant database 7 for processing. 

4 Following are exaxaples of code for an MEX^ script, as fiom steps 40 or 62. 

5 Assuming the machine data ardiiving service or I4DAS web site 16 has the fictional URL 

6 (imifonn resource locator) exan9le-11ri.net and a spedficmendmit has a meitha^ 

7 identifier MMM, a line of HTML code is added at stqp 40 to the transaction form of 

8 meixhantMMMb^een the <fi>niP' and <yfi>niP> HTML tags ii^c^ 
9 

10 <Scriptsrc=iitlpsy/www.exaniple-url.net/s/?MMN^^ 
11 

1 2 When the customs browser 28 processes the transaction form at step 42, it 

13 requests a smpt file fix)m the source URL: https://www.example-iiilnet/s/7MMM. 

14 At step 44, the customs web browse 2S requests the MDC soipt by way of the 

15 Ml' JLt protocol. The m il' request indudes the metdxaat ID MMM, the user agmt 

1 6 (browser version), the IP address of tiie customer's HTTP pr(«y, and any HTTP cookies 

17 previou^ sent to the customs- by www.«(an9le-uri.net Upon receiving this 

1 8 information, the ardiive service 16 records this information in a madune data riecord 

1 9 which also includes the transaction ID. 

2 0 Upon recdving the file request, the arduve service 16 generates a unique 

2 1 transaction ID (represented below as ZZZ) at st^ 46 to be associated with the transaction 

20 
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1 and the madiine parameter set. An ecemplaiy transaction ID is a string of241^ers and 

2 digits. Thefirstdghtd|^formatime-stanq).v^c^isahexade(mnalreprese^ 

3 the seconds elapsed since midnight January 1, 1970 UTC (coordinated universal time). 

4 In tiie preferred embodiment of the process 1, the MDC script is Tvritten in an 

5 ECMASoipt compliant language, sudi as JavaScxipt, JSaipt, or VBSoipt A JavaScript 

6 vendon of the MDC script is as follows (Qndireaks and indentations added fi>r darily): 
7 

8 document.mite(''<1nput name^^transactionid typcF^hidden vahie=2ZZ>, 

9 

10 d=iiewDateO; 
11 

12 t=3600M.getHours()^^0*d.getMuiutes()+d.getSeGondsO; 
13 

14 docum^.vvrite("<lmg heig|h1?=l vddtl^l src=ht^s://www.exan9te- 

15 uri.net/i/?i=^ZZ&t?«"+t+">"); 
16 

17 documenfwrite(''<applet heighfr=l widtli=l 

18 codebase=4it^s://www.e}cample-iirl.net/ 

19 code=a/?ZZZ> 

2 0 <param name=i vahie=2ZZxyapplet>"); 

21 



21 



wo 01/97134 



PCT/USOl/18076 



1 The exemplaiy MDC soipt includes the unique tnmsaction ID value in several 

2 places. When tiie script executes cm the customa-conq)uta- 203 vfdtes HTML ^ 

3 the merchant's order fonn. Spedficalty: 

4 1> The sci^t adds a hidden variable called "transactionid" to the merchant's 

5 transaction form and assigns it the value ofthe transaction ID (ZZZ). When the 

6 transaction form is submitted, the merdiant recdves the transaction ID and can associate 

7 it with the transaction data record. 

8 2) The soipt computes the seconds elapsed since midnight on the clodc 32 

9 and writes a request for a 1 pixel by liHxel image. Inchided in the request is the 

1 0 transaction ID and the time value. When the request executes, Has data is sent back to the 

1 1 archive s^ce 16 and recorded with the transaction ID in the MDAS archive 17. 

12 3) The script adds a request for a program located at the archive s^cewetx 

13 ate 16\diich,inthisexanq>le,isaJavaapplet The applet downloads to the customer 

14 con^ut^ 20 fix>m the archive service 16 and executes, appearing as a I pixd 1 pxel 

15 image on the transaction form. The transaction ID is passed to the program as a 

16 parameter spedfied in the soipt. The program p^orms three tasks: 

17 a) it calculates TTT, the seconds elapsed since midnight on the syst&n dock 

18 32; 

13 b) it calculates AAA, the address ofthe customer 20 on its own local area 

20 network 24; and 

22 
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1 c) it sends this data back to the archive service 16 via TCP/IP, by requesting 

2 the following ORL: 

3 http://ww.example-url.net/d/?i==ZZZ&t=TTT&a==A 

4 The arcMve service 16 recdves the message which includes the parameters TTT, 

5 AAA,andZZZ. The message also includes the ^ address of the sender. This address is 

6 the customer's actual IP address, i;^ch in some cases is difi^ent from the HTTP proxy IP 

7 address. The archive service 16 records this mformation in the MDAS archive 17 and 

8 associates it with the transaction ID ZZZ. 

9 The machine data collection and archiving process 1 of the present invention has 

1 0 been described with a particular application in fraud detection. However, it is foreseen 

1 1 that the techniques of the present invention have a wid^ application, as for marketing or 

12 computer support purposes, or other fiinctions. Wlule the process 1 has been desaibed 

1 3 with reference to the internet 4 or worid wide web, it is also concdvable that the process 1 

1 4 could be employed on computer networks of less than global e?q>anse, such as a large 

1 5 intranet, a national or regional network, or the like. 

1 6 Therefore, it is to be imderstood that while certam forms of the present invention 

1 7 have been illustrated and described herein, the present invention is not intended to be 

1 8 limited to the specific forms, arrangement of parts, sequends of steps, or particular 

1 9 applications desaibed and shown. 
20 
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CLAIMS 

What is claimed and demred to secure by Letters Patent is: 
1 . A process for collecting machine identifying infomiation associated vMi a digital 
online access device used for substantially anonymously acces^ng a host computer 
system over a digital network, said host computer sfystem generating an interaction 
record of an access therewith by said access device, and said process compri^g 
the steps of: 

(a) capturing a machine identifying profile parameter upon said access device 
accessing said host compute system; 

(b) generating a unique interaction identification string upon said access device 
acces^g said host computer systen^ 

(c) associating said interaction identification string with said profile parameter; 
and 

(d) assodating said interaction identification string with said int^action record 
generated upon said access device accessmg said host computer system. 

2. A process as set forth in Claim 1 wherein said capturing step includes the step of: 
(a) capturing a digital address of said access device on said digital network. 

3 . A process as set forth in Qska 1 wherem said capturing step inchides the step o£ 
(a) capturing a configuration setting of said access device. 
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4. A process as set forth in Claim 1 and including the steps of: 

(a) communicating a self-identification routine to said access device upon said 
access device accessing said host computer system; 

(b) said access device ^ecuting said self-identification routine; 

(c) said self-identification routine, queiying a configuration setting of said 
access device to. derive said profile parameter; and 

(d) said self-identification routine communicating said profiOle parameter to a 
remote location for assodation with said interaction identification string. 

5. A process as set forth in Claim 1 and including the steps o£ 

(a) sdd host system operating a host web site including an interaction page 
generated by interaction page code processed by said access device upon 
accessmg said host web site; and 

(b) coding, within said interaction page code, a self-identification routine 
wfaidi causes said access device to communicate said profile parameter 
when said access device processes said interaction page code. 

6. A process as set forth in Claim 3 and includii^ the i^ep of: 

(a) coding smd setf-identification routine in such a manner that said profile 
parameter and said interaction identification string are communicated to a 
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third party web site at ^'^ch said profile parameter and said interaction 
identification string are stored. . 

7. A process for identi^g a customer computer involved in an online transaction 
between a customer using a customer browse operating on said customer 
computer and a merchant operating a merchant web site, said method comprising 
the steps of: 

(a) capturing a customs computer profile paramet^ upon said customer 
computer accessing said merchant web site; 

(b) generating a transaction identification string and assodaling said string 
with said parametei; 

(c) storing said parameter and said string in a machine data archive; 

(d) upon said customer completing a transaction through said merchant w^ 
^te, storing said transaction identification string i;vith a transaction record 
formed during said transaction to thereby assodate smd parameter with 
said transaction record through said string. 

8. A process as set forth in Clahn 7 vdierein said capturing step includes the step of: 
(a) capturing an IP address of said customer computer. 
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9. A process as set forth in Claim 7 wherein said capturing step inchides the step of: 
(a) capturing a configuration setting of said customer compute. 

10. A process as set forth in Gaim 7 and includmg the step of: 

(a) communicating said profile parameter and said transaction identification 
string to a third party web site for storage. 

11. A process as set forth in Claim 7 and including the step of: 

(a) causing said customer computer to communicate said profile parameter and 
said transaction identification string to a thurd party web site for storage. 

12. A process as set forth in Claim 7 and including the steps of: 

(a) communicating a sdf-identification routine to said customer computer 
upon said customer computer accessing said merchant web site; 

(b) said customer computer ^ecuting said self-identification routine; 

(c) said self-identification routine querying a configuration setting of said 
customer computer to derive said profile parameter; and 

(d) said self-identification routine communicatiiig smd profile parameter to a 
remote location for assodation with said interaction identification string. 
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13. A process as set fordi in Cl^ 12 and inclu(&ig the step o£ 

(a) coding said self-identification routine in such a manner that said profile 
parameter and said interaction identification string are communicated to a 
third party weh site at vdiich said profile parameter and said interaction 
identification string are stored. 

14. A process as set forth in Claim 12 wherein said querying step includes the steps of 

(a) querying said customer browser for a plurality of configuration settings; 

(b) forming an attribute string firom said plurafity of configuration settings; and 

(c) processing said attribute string to form said profile parameter of said 
customs computer. 

15. A process as set forth in Claim 12 wherehi said customer computer potmtiaSy 
accesses said merchant web site by way of a pro>gr, and said communicating step 
includes the steps of: 

(a) communicating said profile paramet^ and said transaction id^itification 
string to said remote web site using a protocol which bypasses said proxy. 

16. A process for identifying a customer compute involved in an online transaction 
through a merchant web site between a customer using a customer browser 
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operating on said customer computer and a merchant who operates said web site, 
said method comprising the steps o£ 

(a) coding a script request witliin a transaction form of said merchant web site; 

(b) processing said script request by said customer browser upon accessing 
said merchant web site to thereby communicate to an archiver web site of a 
machine data archiving service an electronic request for a maclune data 
collection script; 

(c) said archiver web site returning said script to said customer browser along 
with a imique transaction identification string 

(d) said customer browser processing said script to thereby cause said script to 
query said customer computer for a profile parameter of said customer 
computer; 

(e) said script causing said customer browsCT to commumcate smd profile 
parameter and said transaction identification string to said arduver web 
site; 

(f) said archiver wdb site storing said profile parameter and said transaction 
identification string in a machine data profile; 

(g) said soipt causing said customer browser tb write said transaction 
identification string into smd transaction form; and 

(h) upon said customer adding customer identification information to said 
transaction form and electronically submitting said transaction form to said 
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merchant web site to thereby comprise a transaction record, said 
transaction identification string assodating said transaction record wi^ said 
machine data profile. 

17. A process as set fi>rth in Claim 16 and including the steps o£ 

(a) said script causing said computer browser to communicate said profile 
parameter and said transaction identification string along with a 
conventional hypertext transfer protocol (HTTP) header, and 

(b) said archiver s^ce additionally storing said HTTP header in assodation 
with said machme data profile. 

18. A process as set forth in Claim 16 and including the step of: 

(a) said script qiuerying said customs browse for a configuration setting 
thereof. 

19. A process as set forth in Claim 16 and including the steps of: 

(a) said script querying smd customer browser for a plurality of configuration 
settings; 

(b) said script forming an attribute string firom said plurality of configuration 
settings; and 
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(c) said script processing said attribute string to form said profile parameter of 
said customer computer/ 

20. A process as set forth in Claim 19 wherein said script processing step includes the 
step of: 

(a) said script pofonmng a hashing fimction on said attribute string to form 
said proftte paramet^. 

A process as set forth in Claim 16 wherein said customer computer potentially 
accesses said merchant web site by way of a proxy, and including the step of: 
(a) smd script communicating said profile parameter and said transaction 

identification string to said archiver service web site using a. protocol which 
bypasses said pro?^. 

A process as set forth in Claim 16 and induding the step of: 
(a) said script communicating said profile parameter to said archiver service 
web site using a protocol other than HTTP. 

23. A process as set forth in Claim 16 wherem said customer computer includes a 
distal clock, and including the steps of: 



21. 
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(a) said soript causing said customer browser to queiy said clock for a time 
vahie;a{id 

(b) said script causing said customer browser to send said time value to said 
archiver service web site along with said profile parameter* 

24. A process for identifying a customer computer involved in an online ttamactton 
through a merchant web site between a customs using a customer browser 
operating on said customer computer and a merchant who operates said web site, 
said method comprising the steps of: 

(a) coding a script request within a transaction form of said merchant web site; 

(b) processing said soipt request by said customs browser upon accessing 
said merchant web site to thereby communicate to . an archiver web site of a 
machine data archiving service an electronic request for a machine data 
collection soipt; 

(c) said archiver we3) ^e retummg said soipt to ssdd customs browser along 
with a unique transaction identification string; 

(d) said customer browser processing said script to thereby cause said script 
to: 

(1) query said customer browser for a plurality of configuration 
settings; 

(2) form an attribute string firom said plurality of configuration settings; 
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(3) perform a hashing function on said attribute string to form said 
profile parameter, and . 

(4) query an internal digital clock of said customer computer for a 
current time value; 

(e) said script causing said customer browser to conununicate said profile 
parameter, said time value, and said transaction identification stimg to said 
archiver web site along vnih a conv^tional HTTP header; 

(f) said archiver web site storing said profile parameter, said time value, and 
said transaction identification string in a machine data profile; 

(g) said script causing said customer browser to write said transaction 
identification string into said transaction fomi; and 

(h) upon said customer adding customer identification information to said 
transaction form and electronically submitting said transaction form to said 
merdiant web site to therd)y comprise a transaction record, said 
transaction idratification string assodating said transaction record with said 
machine data profile. 

25. A process as set forth in Claim 24 i^er^in said customer computer potentially 
accesses said merchant web site by way of a proxy, and including the steps o£ 
(a) said script querying said customer compute for a second profile parameter; 
and 
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(b) said script commumcatmg said second profile parameter and said 

transaction identification- string to said arddver service wet> site uang a 
protocol -whicti bypasses said pro^. 

26. A process as set forth in €3aim 25 and induing the step of: 

(a) said script communicating said second profile parameter to said arcluver 
sendee web ate mng a protocol other than HTTP. 
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